This one is driving me batty! I filter my file servers security log to show only FAILURE AUDITS and I get hit with 100's of event 560's reading:Event Type:Failure AuditEvent Source:SecurityEvent Category:Object Access Event ID:560Date:11/5/2009Time:4:29:32 PMUser:Dom\UserComputer:SERVERNAMEDescription:Object Open:Object Server:SecurityObject Type:FileObject Name:MAPPEDDRIVE:\FOLDER\FOLDER\FOLDER\desktop.iniHandle ID:-Operation ID:{0,389448647}Process ID:4Image File Name:Primary User Name:SERVERNAME$Primary Domain:DOMAINPrimary Logon ID:(0x0,0x3E7)Client User Name:USERNAMEClient Domain:DOMAINClient Logon ID:(#x#,#x##C##EE#)<-"#" = that a number has been removed Accesses:ReadAttributes Privileges:-Restricted Sid Count:0Access Mask:0x80 For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.The user that the event refers to is not the owner of the file, that much I get; but why a desktop.ini file (I thought those were files that held folder display settings)? Not to mention there are 25 occurances in less then 50 sec. can anyone help me out here?

Well, here is what is happeningIts a failure to Read Attibutes of the specified Desktop.ini file. Attributes setting configurable via the attrib.exe command.R Read-only file attribute.A Archive file attribute.S System file attribute.H Hidden file attribute.So, my first observation is this:Reading a files attibutes isn't an AUDITABLE action, and you should change your audit policy. Recommended NTFS Audit Policy http://networkadminkb.com/kb/Knowledge%20Base/Windows2003/Recommended%20NTFS%20Audit%20Policy.aspxIf you must audit this: then to avoid the failure give the users the Allow - Read Attibbutes privledge via the Advanced button on the security tab.

Gunner,This audit policy is strictly for logging success and failure for file access by users, so how could a user be accessing a desktop.ini that is 1 level deeper then their permissions will let them go? There are no failed attempts to gain access to the parent folder.

Their not accessing the parent folder, this audit is onlytelling you that they request ReadAttibutes to this file...and that was denied. That'show a failure audit works.Your assuming the cart before the horse i think. I don't think the audit is lying to you, so either your assumption about your security is wrong, or the most likey answer is that since the request wasn't for the folder above, the audit didn't report on it.